Subject: UDP Checksums

From: [email-masked] (Erickson, Rodger)
Date: Tue, 09 Apr 1996 07:49:38 -0700

Greetings,

     After the recent AIW, I decided to do a little research on UDP 
checksums.  It turns out that their use is optional and that many 
implementations have historically ignored them due to a bug in the BSD 
implementation (however, this bug has been fixed).

     If we don't use the UDP checksum for Multicast and Unicast, we have no 
way of making sure that what we receive is accurate.  This could be 
especially bad if the data is garbled slightly but still appears to be valid 
(especially for NetBIOS sessions).  It is one thing to assume that a packet 
we Multicast or Unicast might get lost.  It is another thing entirely to 
assume that DLSw may have received a packet that is just plain wrong 
(especially if it somehow looks right!).
     If we don't use UDP checksums, we would need to develop our own DLSw 
checksums to ensure that data that is delivered is, in fact, accurate.

     I propose just going ahead and making UDP checksums a required part of 
any document that specifies either Multicasting or Unicasting.

     Comments?

     Rodger Erickson
     Wall Data

---

From: [email-masked] (Erickson, Rodger)
Date: Tue, 09 Apr 1996 08:10:31 -0700

I didn't get any responses on the posting below so I'm resending.  I 
don't need to hear back from everyone but I'd at least like to hear from 
Dave Bryant...

     Rodger Erickson
     Wall Data
 ----------
From: Erickson, Rodger
To: 'DLSw Scalability'
Subject: UDP Checksums
Date: Tuesday, April 02, 1996 6:47PM

     Greetings,

     Comments?

     Rodger Erickson
     Wall Data

---

From: David Bryant/HQ/3Com <[email-masked]>
Date: 12 Apr 96 17:27:50 EDT

Rodger -

I'm not sure I agree with your proposal to require UDP checksums in DLSw
Multicast.  Here are my reasons why:

1). It's not clear that everyone's UDP stack has the capability to support 
this function

2). The probability of packet corruption is actually fairly low

Assuming every datalink implements a checksum function (and I believe they do), 
then the packet cannot be corrupted and successfully passed over the link.
So this protects up to Layer 3.  This means the only possibility of packet 
corruption is 
if an implementation actually corrupts the packet in their IP layer (before 
transmitting
out to the next host).

3). The problem already exists with DLSw RFC 1795/1434

It is possible to encounter the same problem today if a DLSw implementation 
corrupts 
a packet between the TCP/IP tunnel and before transmitting the packet out of 
the box 
(SDLC/LLC2). 

But, if it turns out that point #1 is a non-issue, then it may be a valuable 
thing for us to add.

-Db